Software vendors strive to provide greater application interoperability to retain and meet the demands of customers. For example, when integrating messaging application functionality into email programs, a greater amount of data in the form of notifications is required to flow constantly from the communications server to the client in a nearly realtime environment. Presence information, request/responses for chat, notification of changes in buddy lists, etc., are examples of data that needs to be readily processed by the server. On the other hand, it is mandatory that the messaging functionality does not compromise nonfunctional requirements such as scalability and performance.
To provide this information delivery capability, two different paradigms that can be employed are a push paradigm or a pull paradigm. In a typical client/server model, a client requests a service or information from the server and the server responds by transmitting the information to the client. This is called a pull technology, in that the client pulls information from the server. In contrast, in push technology, the request for a given transaction originates with the server.
Continuing with the example of messaging applications, messaging demands a fast client communication for meeting the demands of an acceptable amount of time for clients to receive a messaging chat notifications coming from other clients. Given this stringent requirement, the use of pull technology is not an attractive solution because it is not scalable and performance inhibited—with small intervals between requests, the number of pulling requests per second is too large to support many users per server.
Although the push model should be the clear choice, the push model presents complications such as increased memory consumption as well as the CPU overhead. Another issue is the implementation of a proxy server between the server and client which closes a connection that has been inactive for an extended period of time.